home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-meyer-demandrouting-00.txt < prev    next >
Text File  |  1993-03-03  |  59KB  |  1,685 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                         G.M. Meyer
  6. Internet Draft                                            Spider Systems
  7. Expires May 14, 1993                                       November 1992
  8.  
  9.  
  10.         Routing over Demand Circuits on Wide Area Networks - RIP
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This memo is being distributed to members of the Internet community
  16.    in order to solicit their reactions to the proposals contained in it.
  17.  
  18.    This document is an Internet Draft.  Internet Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its Areas,
  20.    and its Working Groups.  Note that other groups may also distribute
  21.    working documents as Internet Drafts.  Internet Drafts are draft
  22.    documents valid for a maximum of six months.  Internet Drafts may be
  23.    updated, replaced, or obsoleted by other documents at any time.  It
  24.    is not appropriate to use Internet Drafts as reference material or to
  25.    cite them other than as a ``working draft'' or ``work in progress.''
  26.    Please check the 1id-abstracts.txt listing contained in the
  27.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  28.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  29.    current status of any Internet Draft.
  30.  
  31.    Distribution of this memo is unlimited.
  32.  
  33. Abstract
  34.  
  35.    Running routing protocols on connection oriented Public Data
  36.    Networks, for example X.25 packet switched networks or ISDN, can be
  37.    expensive if the standard form of periodic broadcasting of routing
  38.    information is adhered to.  The high cost arises because a connection
  39.    must to all practical intents and purposes be kept open to every
  40.    destination to which routing information is to be sent, whether or
  41.    not it is being used to carry user data.
  42.  
  43.    Routing information may also fail to be propagated if the number of
  44.    destinations to which the routing information is to be sent exceeds
  45.    the number of channels available to the router on the Wide Area
  46.    Network (WAN).
  47.  
  48.    This memo defines a generalized modification which can be applied to
  49.    Bellman-Ford (or distance vector) algorithm information broadcasting
  50.    protocols, for example IP RIP, Netware RIP or Netware SAP, which
  51.    overcomes the limitations of the traditional methods described above.
  52.    The routing protocols support a purely triggered update mechanism on
  53.  
  54.  
  55.  
  56. Meyer                                                           [Page 1]
  57.  
  58. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  59.  
  60.  
  61.    demand circuits on WANs.  The protocols run UNMODIFIED on LANs or
  62.    fixed point-to-point links.
  63.  
  64.    Routing information is sent on the WAN when the routing database is
  65.    modified by new routing information received from another interface.
  66.    When this happens a (triggered) update is sent to a list of
  67.    destinations on other WAN interfaces.  Because routing protocols are
  68.    datagram based they are not guaranteed to be received by the peer
  69.    router on the WAN.  An acknowledgement and retransmission mechanism
  70.    is provided to ensure that routing updates are received.
  71.  
  72.    To avoid unnecessary load when a connection to a destination is not
  73.    currently available (possibly because of channel starvation) the
  74.    circuit manager advises the routing applications on the reachability
  75.    and non-reachability of destinations on the WAN.
  76.  
  77. Acknowledgements
  78.  
  79.    I would like to thank colleagues at Spider, in particular Tom Daniel
  80.    and Richard Edmonstone, for discussions and comments which helped to
  81.    clarify this memo.
  82.  
  83. Conventions
  84.  
  85.    The following language conventions are used in the items of
  86.    specification in this document:
  87.  
  88.    o  MUST -- the item is an absolute requirement of the specification.
  89.       MUST is only used where it is actually required for interopera-
  90.       tion, not to try to impose a particular method on implementors
  91.       where not required for interoperability.
  92.  
  93.    o  SHOULD -- the item should be followed for all but exceptional cir-
  94.       cumstances.
  95.  
  96.    o  MAY or optional -- the item is truly optional and may be followed
  97.       or ignored according to the needs of the implementor.
  98.  
  99.       The words "should" and "may" are also used, in lower case, in
  100.       their more ordinary senses.
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Meyer                                                           [Page 2]
  113.  
  114. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  115.  
  116.  
  117.  
  118.                           Table of Contents
  119.  
  120.       1. Introduction ...........................................  4
  121.  
  122.       2. Running a routing Protocol on the WAN ..................  6
  123.           2.1. Overview .........................................  6
  124.           2.2. Presumption of Reachability ......................  8
  125.           2.3. WAN Router list ..................................  8
  126.           2.4. Triggered Updates and Unreliable Delivery ........  9
  127.           2.5. Guaranteeing delivery of Routing Updates .........  9
  128.           2.6. The Routing Database ............................. 10
  129.           2.7. New Packet Types ................................. 11
  130.           2.8. Fragmentation .................................... 12
  131.           2.9. Preventing Queue Overload ........................ 13
  132.  
  133.       3. IP Routing Information Protocol Version 1 .............. 14
  134.  
  135.       4. IP Routing Information Protocol Version 2 .............. 17
  136.  
  137.       5. Netware Routing Information Protocol ................... 18
  138.  
  139.       6. Netware Service Advertising Protocol ................... 22
  140.  
  141.       7. Timers ................................................. 26
  142.           7.1. Database Timer ................................... 26
  143.           7.2. Retransmission Timer ............................. 27
  144.           7.3. Reassembly Timer ................................. 27
  145.  
  146.       8. Security Considerations ................................ 28
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Meyer                                                           [Page 3]
  169.  
  170. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  171.  
  172.  
  173. 1. Introduction
  174.  
  175.    Routers are used on connection oriented networks, such as X.25 packet
  176.    switched networks and ISDN networks, to allow potential connectivity
  177.    to a large number of remote destinations.  Circuits on the Wide Area
  178.    Network (WAN) are established on demand and are relinquished when the
  179.    traffic subsides.  Depending on the application, the connection
  180.    between any two sites for user data might actually be short and rela-
  181.    tively infrequent.
  182.  
  183.    Practical experience of routing shows that periodic 'broadcasting' of
  184.    routing updates on the WAN is unsatisfactory on several counts:
  185.  
  186.    o  Running a routing protocol like RIP is expensive if the standard
  187.       form of transmitting routing information to EVERY remote router
  188.       every 30 seconds is adhered to.  The more routers there are wish-
  189.       ing to exchange information the worse the problem.  If there are N
  190.       routers on the WAN, N * (N - 1) routing updates are sent over N *
  191.       (N - 1)/2 connections every broadcast period.
  192.  
  193.       The cost arises because a circuit must be kept open to each desti-
  194.       nation to which routing information is to be sent.  Routing
  195.       updates are sufficiently frequent, that little benefit is obtain-
  196.       able on most networks, by attempting to set up a call purely for
  197.       the duration of the routing update (there are often minimum call
  198.       charges, where the first data is 'free').
  199.  
  200.       The option of reducing the 'broadcast' frequency, while reducing
  201.       the cost, would make the system less responsive.
  202.  
  203.    o  The number of networks to be connected (N) on the WAN can easily
  204.       exceed the number of simultaneous calls (M) which the interface
  205.       can support.  If this happens the routing 'broadcast' will only
  206.       reach M next hop routers, and (N - M) next hop routers will not
  207.       receive the routing update.
  208.  
  209.       A basic rate ISDN interface can support 2 simultaneous calls, and
  210.       even the number of logical channels most users subscribe to on an
  211.       X.25 network is not large.  There is no fundamental reason why
  212.       routing protocols should restrict the user to run routing between
  213.       so few sites.
  214.  
  215.    o  Since there is no broadcast facility on the WAN, 'broadcasting' of
  216.       routing information actually consists of sending the updates
  217.       separately to all known locations.  This means that N routing
  218.       updates are queued for transmission on the WAN link (in addition
  219.       to any data which might be queued).
  220.  
  221.  
  222.  
  223.  
  224. Meyer                                                           [Page 4]
  225.  
  226. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  227.  
  228.  
  229.       Routers take a pragmatic view on queuing datagrams for the WAN.
  230.       If the queue length gets too long, so that datagrams at the end of
  231.       the queue would take too long be transmitted in a reasonable time
  232.       (say 1 to 2 seconds) the router may start discarding them.  On an
  233.       X.25 network, with slow line speeds (perhaps 9600 baud), it may
  234.       not take too many routing updates to fulfill this condition if the
  235.       link is also actively being used to carry user data.
  236.  
  237.    This memo addresses all the above problems.
  238.  
  239.    The approach taken is to modify the routing protocols so as to send
  240.    information on the WAN only when there has been an update to the
  241.    routing database OR a change in the reachability of the remote desti-
  242.    nation is indicated by the task which manages connections on the WAN.
  243.  
  244.    Because datagrams are not guaranteed to get through, an acknowledge-
  245.    ment and retransmission system is required.  This memo describes the
  246.    modifications required for Bellman-Ford (or distance vector) algo-
  247.    rithm information broadcasting protocols, such as IP RIP [1,2],
  248.    Netware RIP [3,5] or Netware SAP [3,6].
  249.  
  250.    A separate working draft will cover modifications to shortest path
  251.    algorithm protocols such as OSPF [8] and IS-IS [9,10] to support the
  252.    triggered update mechanism.
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280. Meyer                                                           [Page 5]
  281.  
  282. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  283.  
  284.  
  285. 2. Running Routing Protocols on the WAN
  286.  
  287. 2.1 Overview
  288.  
  289.    Multiprotocol routers are used on connection oriented Wide Area Net-
  290.    works (WANs), such as X.25 packet switched networks and ISDN net-
  291.    works, to interconnect Local Area Networks (LANs).  By using the mul-
  292.    tiplexing properties of the underlying WAN technology, several LANs
  293.    can be interconnected simultaneously through a single physical inter-
  294.    face on the router.
  295.  
  296.    A circuit manager provides an interface between the connectionless
  297.    network layers (IP, IPX, CLNP etc) and the connection oriented WAN
  298.    (X.25 or ISDN).  Figure 1 shows a schematic representative stack
  299.    showing the relationship between routing protocols, the network
  300.    layers, the circuit manager and the connection oriented WAN.
  301.  
  302.  
  303.         --------------       ---------  ---------         -------------
  304.         |    RIP     |       |  RIP  |  |  SAP  |         |   IS-IS   |
  305.         --------------       ---------  ---------         -------------
  306.               |                  |          |                   |
  307.         --------------           |          |                   |
  308.         |    UDP     |           |          |                   |
  309.         --------------           |          |                   |
  310.               |                  |          |                   |
  311.         --------------         ----------------           -------------
  312.         |    IP      |         |     IPX      |           |   CLNP    |
  313.         --------------         ----------------           -------------
  314.               |                       |                         |
  315.         ---------------------------------------------------------------
  316.         |                       Circuit Manager                       |
  317.         ---------------------------------------------------------------
  318.                                   ||||||||||
  319.                                   ||||||||||
  320.                           ---------------------------
  321.                           |   Connection Oriented   |
  322.                           |        WAN stack        |
  323.                           ---------------------------
  324.  
  325.      A WAN circuit manager will support a variety of network layer  pro-
  326.      tocols,  on  its  upper  interface.  On its lower interface, it may
  327.      support one or more subnetworks.  A subnetwork may support a number
  328.      of Virtual Circuits.
  329.  
  330.  
  331.             Figure 1.   Representative Multiprotocol Router stack
  332.  
  333.  
  334.  
  335.  
  336. Meyer                                                           [Page 6]
  337.  
  338. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  339.  
  340.  
  341.    The router has a translation table which relates the network layer
  342.    address of the next hop router to the physical address used to estab-
  343.    lish a Virtual Circuit (VC) to it.  Datagrams may be encapsulated in
  344.    a header to distinguish the network layer protocol [11].
  345.  
  346.    The circuit manager takes datagrams from the connectionless network
  347.    layer protocols and (if one is not currently available) opens a VC to
  348.    the next hop router.  A VC can carry all traffic between two end-
  349.    point routers for a given network layer protocol (or with appropriate
  350.    encapsulation all network layer protocols).  An idle timer is used to
  351.    close the VC when the datagrams stop arriving at the circuit manager.
  352.  
  353.    Running routing protocols on the WAN has traditionally consisted of
  354.    making small modifications to the methods used on LANs.  Where rout-
  355.    ing information would be broadcast periodically on a LAN interface,
  356.    it is converted to a series of periodic updates sent to a list of
  357.    addresses on the WAN.
  358.  
  359.    This memo targets two areas:
  360.  
  361.    o  Eliminating the overkill inherent in periodic transmission of
  362.       routing updates.
  363.  
  364.    o  Overcoming the bandwith limitations on the WAN: the number of
  365.       simultaneous VCs to next hop routers and restricted data
  366.       throughput which the WAN link can support.
  367.  
  368.    The first of these is overcome by transmitting routing updates
  369.    (called routing responses) only when required:
  370.  
  371.    o  Firstly when a specific request for a routing update has been
  372.       received.
  373.  
  374.    o  Secondly when the routing database is modified by new information
  375.       from another interface.
  376.  
  377.    o  Thirdly when the circuit manager indicates that a destination has
  378.       changed from an unreachable (circuit down) to a reachable (circuit
  379.       up) state.
  380.  
  381.    Because of the inherent unreliability of a datagram based system,
  382.    both routing requests and routing responses require acknowledgement,
  383.    and retransmission in the event of NOT receiving an acknowledgement.
  384.  
  385.    To overcome the bandwidth limitations the routing application can
  386.    perform a form of self-imposed flow control, to spread routing
  387.    updates out over a period of time.
  388.  
  389.  
  390.  
  391.  
  392. Meyer                                                           [Page 7]
  393.  
  394. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  395.  
  396.  
  397. 2.2 Presumption of Reachability
  398.  
  399.    If a routing update is received from a next hop router on the WAN,
  400.    entries in the update are thereafter always considered to be reach-
  401.    able, unless proven otherwise:
  402.  
  403.    o  If in the normal course of routing datagrams, the circuit manager
  404.       fails to establish a connection to the next hop router, it noti-
  405.       fies the routing application that the next hop router is not
  406.       reachable through an internal circuit down message.
  407.  
  408.       The routing application then goes through a process of timing out
  409.       database entries to make them unreachable in the routing sense.
  410.  
  411.    o  If the circuit manager is subsequently able to establish a connec-
  412.       tion to the next hop router, it will notify the routing applica-
  413.       tion that the next hop router is reachable through an internal
  414.       circuit up message.
  415.  
  416.       The routing application will then exchange messages with the next
  417.       hop router so as to re-prime their respective routing databases
  418.       with up to date information.
  419.  
  420.    Handling of circuit up and circuit down messages requires that the
  421.    circuit manager takes responsibility for establishing (or re-
  422.    establishing) the connection in the event of a next hop router being
  423.    unreachable.  A description of the processes the circuit manager must
  424.    adopt to perform this task is outside the scope of this memo.
  425.  
  426. 2.3 WAN Router list
  427.  
  428.    The routing task MAY be provided with a list of routers to send rout-
  429.    ing updates to on the WAN.  It will comprise of the logical addresses
  430.    of next hop routers for which the router has a logical to physical
  431.    address mapping.  Entries in the list SHOULD be categorized (on a
  432.    per-peer basis) as follows:
  433.  
  434.    o  Running the standard routing protocol, namely transmitting updates
  435.       periodically using packet formats used in LAN broadcasts.
  436.  
  437.       This option is supported to allow interoperability with existing
  438.       routing implementations, and might also be appropriate if some of
  439.       the destinations are using Permanent Virtual Circuits (PVCs)
  440.       rather than SVCs.
  441.  
  442.    o  Running the triggered update routing protocol proposed in this
  443.       memo.
  444.  
  445.  
  446.  
  447.  
  448. Meyer                                                           [Page 8]
  449.  
  450. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  451.  
  452.  
  453.    Omitting an address from either of these categories is equivalent to
  454.    not running the routing protocols.
  455.  
  456.    If routing packets arrive from a destination not supporting the
  457.    appropriate variant they MUST be discarded.
  458.  
  459. 2.4 Triggered Updates and Unreliable Delivery
  460.  
  461.    If triggered update information is sent to next hop routers on the
  462.    WAN only once it can fail to arrive for one of the following reasons:
  463.  
  464.    o  A free VC resource might not be available, because of a restricted
  465.       number of X.25 logical channels or ISDN B-channels.
  466.  
  467.    o  The transmit queue might be full - requiring the datagram to be
  468.       discarded.
  469.  
  470.    o  The VC might be pre-empted (in favour of establishing a VC to
  471.       another next hop router) while the datagram is in a queue, result-
  472.       ing in the queue being flushed and the datagram discarded.
  473.  
  474.    o  In cases where the method of transport is not guaranteed, for
  475.       example with PPP where there is no acknowledgement and retransmis-
  476.       sion of HDLC frames, a corrupted frame will result in the loss of
  477.       the datagram.
  478.  
  479. 2.5 Guaranteeing delivery of Routing Updates
  480.  
  481.    To guarantee delivery of routing updates on the WAN an acknowledge-
  482.    ment and retransmission scheme MUST be used:
  483.  
  484.    o  Send a routing update to a next hop router on the WAN.
  485.  
  486.    o  The other router updates its routing database with the new infor-
  487.       mation, and responds with an acknowledgement packet.
  488.  
  489.       The original router receives the acknowledgement.
  490.  
  491.    o  Otherwise the original router retransmits the update until an ack-
  492.       nowledgement is received.
  493.  
  494.       In cases where the routing database is modified before an ack-
  495.       nowledgement is received a new routing update with an updated
  496.       sequence number is sent out.  If an acknowledgement for the old
  497.       routing update is received it is ignored.
  498.  
  499.    The above mechanism caters for cases where the datagram is lost
  500.    because of a frame error or is discarded because of an over-full
  501.  
  502.  
  503.  
  504. Meyer                                                           [Page 9]
  505.  
  506. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  507.  
  508.  
  509.    queue.  The routing update and acknowledgment will eventually both
  510.    get through.
  511.  
  512.    In cases where the circuit manager cannot establish a connection, a
  513.    mechanism is provided to allow the circuit manager to inform the
  514.    routing task of the failure to make a connection so that it can
  515.    suppress retransmissions until a circuit becomes available.
  516.  
  517. 2.6 The Routing Database
  518.  
  519.    A requirement of using triggered updates for propagating routing
  520.    information is that NO routing information must ever get LOST or DIS-
  521.    CARDED.
  522.  
  523.    The routing database MUST keep all alternative routing information it
  524.    learns from any routing updates, so that if the best route(s) disap-
  525.    pear an alternative route (if available) can replace it as the new
  526.    best route.
  527.  
  528.    If the amount of memory this consumes is problematic, this can be
  529.    re-interpreted as:
  530.  
  531.    o  The routing application must keep SOME alternative routing infor-
  532.       mation, and be aware of what has been discarded so that it can
  533.       request the discarded information before its effect is noticed.
  534.  
  535.    Entries in the routing database can either be permanent or temporary.
  536.    Entries learned from broadcasts on LANs are temporary. They will
  537.    expire if not periodically refreshed by further broadcasts.
  538.  
  539.    Entries learned from a triggered response on the WAN are 'permanent'.
  540.    They MUST not time out in the normal course of events.
  541.  
  542.    The entries state MUST be changed to 'temporary' by the following
  543.    events:
  544.  
  545.    o  The arrival of a routing update containing the entry set to
  546.       unreachable.
  547.  
  548.       The normal hold down timer MUST be started, after which the entry
  549.       disappears from the routing database.
  550.  
  551.    o  The arrival of a routing update with the entry absent.
  552.  
  553.       If the hold down timer is not already running, the entry MUST be
  554.       set to unreachable and the hold down timer started.
  555.  
  556.    o  A message sent from the circuit manager, to indicate that it
  557.  
  558.  
  559.  
  560. Meyer                                                          [Page 10]
  561.  
  562. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  563.  
  564.  
  565.       failed to make a connection in normal running.
  566.  
  567.       The routing table MUST be scanned for all routes via that next hop
  568.       router.  Aging of these routing entries MUST commence (which for
  569.       IP RIP runs for 180 seconds).  If that period runs out, the entry
  570.       MUST be set to unreachable, and the hold down timer started.  If
  571.       the hold down timer expires the entry disappears from the routing
  572.       database.
  573.  
  574.    o  If the interface goes down, the circuit manager should indicate
  575.       that all circuits on that interface have gone down.
  576.  
  577. 2.7 New Packet Types
  578.  
  579.    To support triggered updates, three new packet types MUST be sup-
  580.    ported:
  581.  
  582.    TRIGGERED REQUEST
  583.  
  584.              A request to the responding system to send all appropriate
  585.              elements in its routing database.
  586.  
  587.              A triggered request is retransmitted at periodic intervals
  588.              until a triggered response is received.  If a response is
  589.              not received after a number of retransmissions, the desti-
  590.              nation should be marked as NOT supporting the mechanism and
  591.              no further routing messages should be sent to that destina-
  592.              tion.
  593.  
  594.              Routing requests are transmitted in the following cir-
  595.              cumstances:
  596.  
  597.              o  Firstly when the router is powered on.
  598.  
  599.              o  Secondly when the circuit manager indicates a destina-
  600.                 tion has been in an unreachable (circuit down) state for
  601.                 an extended period and changes to a reachable (circuit
  602.                 up) state.
  603.  
  604.              o  Thirdly in the event of all routing update fragments
  605.                 failing to arrive within a set period.
  606.  
  607.              o  It may also send triggered requests at other times to
  608.                 compensate for discarding non-optimal routing informa-
  609.                 tion.
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616. Meyer                                                          [Page 11]
  617.  
  618. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  619.  
  620.  
  621.    TRIGGERED RESPONSE
  622.  
  623.              A message containing all appropriate elements of the rout-
  624.              ing database, An appropriate element is an entry NOT
  625.              learned from the interface to which the routing information
  626.              is being sent out.  This is known as "split horizon".
  627.  
  628.              A triggered response message may be sent in response to a
  629.              triggered request, or it may be an update message issued
  630.              because of a change in the routing database.
  631.  
  632.              A triggered response is retransmitted at periodic intervals
  633.              until a triggered acknowledgement is received.  If an ack-
  634.              nowledgement is not received after a number of retransmis-
  635.              sions, the destination should be marked as NOT supporting
  636.              the mechanism and no further routing messages should be
  637.              sent to that destination.
  638.  
  639.    TRIGGERED ACKNOWLEDGEMENT
  640.  
  641.              A message sent in response to every triggered response
  642.              packet received.
  643.  
  644.    Before marking the destination as not supporting the mechanism, at
  645.    least 10 retransmissions (without acknowledgement) should be sent.
  646.  
  647.    When a destination is marked as down, routes through it should be
  648.    marked as unreachable for the duration of a hold down timer before
  649.    being deleted.
  650.  
  651.    If a destination marked as not supporting the mechanism, subsequently
  652.    sends a valid 'triggered' message, the destination should be marked
  653.    as supporting the mechanism once more (to allow for the next hop
  654.    router's configuration being changed).  It should be sent a triggered
  655.    request and a triggered response to obtain and propagate up to date
  656.    routing information.
  657.  
  658.    Triggered response and triggered acknowledgement packets MUST contain
  659.    additional fields to contain a sequence number, fragment number and
  660.    number of fragments.
  661.  
  662. 2.8 Fragmentation
  663.  
  664.    If a routing update is sufficiently large, the information MUST be
  665.    fragmented over several triggered response packets:
  666.  
  667.    o  Each fragment MUST be individually acknowledged with a triggered
  668.       acknowledgement packet.
  669.  
  670.  
  671.  
  672. Meyer                                                          [Page 12]
  673.  
  674. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  675.  
  676.  
  677.       The sender of the routing update MUST periodically retransmit
  678.       fragments which have not been acknowledged (or until the destina-
  679.       tion is marked as not supporting the mechanism).
  680.  
  681.    o  A router receiving fragments MUST re-assemble them before updating
  682.       its routing database.
  683.  
  684.    o  If all fragments are not received within four times the retransmit
  685.       period, they MUST be discarded.
  686.  
  687.       A triggered request packet MUST then be sent to the originator of
  688.       the routing update.
  689.  
  690.       On receiving the triggered request packet, the originator of the
  691.       routing update MUST retransmit ALL fragments.
  692.  
  693.    o  If a fragment with an updated sequence number is received, ALL
  694.       fragments with the earlier sequence number MUST be discarded.
  695.  
  696. 2.9 Preventing Queue Overload
  697.  
  698.    In order to prevent too many routing messages being queued at a WAN
  699.    interface, the routing task MAY operate a scheme whereby 'broadcast-
  700.    ing' of a triggered request or triggered response to a WAN interface
  701.    is staggered.  All routing requests or routing responses are not sent
  702.    to ALL next hop routers on the interface in a single batch:
  703.  
  704.    o  The routing task should limit the number of outstanding triggered
  705.       request messages for which a triggered response has not been
  706.       received.
  707.  
  708.    o  The routing task should limit the number of outstanding triggered
  709.       response messages for which a triggered acknowledgement has not
  710.       been received.
  711.  
  712.    As outstanding messages are appropriately acknowledged, further mes-
  713.    sages can be sent out to other next hop routers, until all next hop
  714.    routers have been sent the message and have acknowledged it.
  715.  
  716.    The maximum number of outstanding messages transmitted without ack-
  717.    nowledgement is a function of the link speed and the number of other
  718.    routing protocols operating the triggered update mechanism.
  719.  
  720.    Messages should always be acknowledged immediately (even if it causes
  721.    the limit to be exceeded), since a connection is almost certainly
  722.    available.  This has the potential benefit of allowing the VC to
  723.    close sooner (on its idle timer).
  724.  
  725.  
  726.  
  727.  
  728. Meyer                                                          [Page 13]
  729.  
  730. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  731.  
  732.  
  733. 3. IP Routing Information Protocol Version 1
  734.  
  735.    This section should be read in conjunction with reference [1].
  736.  
  737.    IP RIP is a UDP-based protocol which generally sends and receives
  738.    datagrams on UDP port number 520.
  739.  
  740.    To support the mechanism outlined in this proposal the packet format
  741.    for RIP version 1 [1] is modified as shown in Figure 2.
  742.  
  743.    Every Routing Information Protocol datagram contains the following:
  744.  
  745.    COMMAND   Commands supported in RIP Version 1 are: request (1),
  746.              response (2), traceon (3), traceoff (4), SUN reserved (5).
  747.              The fields sequence number, fragment number and number of
  748.              fragments MUST NOT be included in packets with these com-
  749.              mand values.
  750.  
  751.              The following new commands (with values in brackets) are
  752.              required:
  753.  
  754.        TRIGGERED REQUEST (6)
  755.  
  756.                  A request for the responding system to send all of its
  757.                  routing database.
  758.  
  759.                  Only the first 4 octets of the packet format shown in
  760.                  figure 2 are sent, since all routing information is
  761.                  implied by this request type.
  762.  
  763.        TRIGGERED RESPONSE (7)
  764.  
  765.                  A message containing all of the sender's routing data-
  766.                  base, excluding those entries learned from the inter-
  767.                  face to which the routing information is being sent.
  768.  
  769.                  This message may be sent in response to a triggered
  770.                  request, or it may be an update message resulting from
  771.                  a change in the routing database.
  772.  
  773.        TRIGGERED ACKNOWLEDGEMENT (8)
  774.  
  775.                  A message sent in response to every triggered response
  776.                  packet received.
  777.  
  778.                  Only the first 8 octets of the packet format shown in
  779.                  figure 2 are sent.
  780.  
  781.  
  782.  
  783.  
  784. Meyer                                                          [Page 14]
  785.  
  786. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  787.  
  788.  
  789.  
  790.      0                   1                   2                   3 3
  791.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  792.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  793.      | command (1)   | version (1)   |      must be zero (2)         |
  794.      +---------------+---------------+-------------------------------+
  795.  
  796.         The following new fields are inserted for some commands
  797.  
  798.      0                   1                   2                   3 3
  799.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  800.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  801.      |    sequence number (2)        | fragment (1)  |no of frags (1)|
  802.      +-------------------------------+-------------------------------+
  803.  
  804.           Followed by up to 25 routing entries (each 20 octets)
  805.  
  806.      0                   1                   2                   3 3
  807.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  808.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  809.      | address family identifier (2) |      must be zero (2)         |
  810.      +-------------------------------+-------------------------------+
  811.      |                         IP address (4)                        |
  812.      +---------------------------------------------------------------+
  813.      |                        must be zero (4)                       |
  814.      +---------------------------------------------------------------+
  815.      |                        must be zero (4)                       |
  816.      +---------------------------------------------------------------+
  817.      |                          metric (4)                           |
  818.      +---------------------------------------------------------------+
  819.                                      .
  820.                                      .
  821.  
  822.      The format of a IP RIP datagram in  octets,  with  each  tick  mark
  823.      representing one bit.    All fields are in network order.
  824.  
  825.      The four octets: sequence  number  (2),  fragment  number  (1)  and
  826.      number of fragments (1) are not present in the original RIP specif-
  827.      ication.   They are only present if command takes the values  7  or
  828.      8.
  829.  
  830.  
  831.           Figure 2.   IP Routing Information Protocol packet format
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840. Meyer                                                          [Page 15]
  841.  
  842. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  843.  
  844.  
  845.    VERSION   In this instance Version 1.
  846.  
  847.    SEQUENCE NUMBER
  848.  
  849.              This is a new field inserted if command takes the values 7
  850.              or 8.
  851.  
  852.              The sequence number MUST be incremented every time updated
  853.              information is sent out on a WAN.  The sequence number
  854.              wraps round at 65535.
  855.  
  856.              When a triggered acknowledgement is sent the sequence
  857.              number is set to the same value as the triggered response
  858.              packet being acknowledged.
  859.  
  860.    FRAGMENT NUMBER
  861.  
  862.              The fragment number is one for the first fragment of a
  863.              routing update, and is incremented for each subsequent
  864.              fragment.  A fragment can contain up to 25 routing entries.
  865.  
  866.              When a triggered acknowledgement is sent the sequence
  867.              number is set to the same value as the triggered response
  868.              packet being acknowledged.
  869.  
  870.              The sequence number MUST be identical over fragments.
  871.  
  872.    NUMBER OF FRAGMENTS
  873.  
  874.              This indicates the number of packets required to complete
  875.              the routing update.
  876.  
  877.              A triggered acknowledgement should return the value
  878.              obtained from the triggered response packet.
  879.  
  880.    ADDRESS FAMILY IDENTIFIER
  881.  
  882.              The address family identifier for IP is 2.
  883.  
  884.    For triggered response packets the rest of the datagram contains a
  885.    list of destinations, with information about each.  Each entry in
  886.    this list contains a destination network or host, and the metric for
  887.    it.  The packet format is intended to allow RIP to carry routing
  888.    information  for several different protocols, identifiable by the
  889.    family identifier.
  890.  
  891.    The IP address is the usual Internet address, stored as 4 octets in
  892.    network order.  The metric field must contain a value between 1 and
  893.  
  894.  
  895.  
  896. Meyer                                                          [Page 16]
  897.  
  898. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  899.  
  900.  
  901.    15 inclusive, specifying the current metric for the destination, or
  902.    the value 16 (representing 'infinity'), which indicates that the des-
  903.    tination is not reachable.  Each route sent by a router supersedes
  904.    any previous route to the same destination from the same router.
  905.  
  906.    The maximum datagram size is 508 octets, excluding UDP and IP
  907.    headers.
  908.  
  909. 4. IP Routing Information Protocol Version 2
  910.  
  911.    An enhancement to IP RIP to include subnetting is currently around as
  912.    a working draft [2].  This section only describes differences from
  913.    that memo.
  914.  
  915.    The triggered update mechanism can be supported by including the
  916.    triggered request (6), triggered response (7) and triggered ack-
  917.    nowledgement (8) commands described in the previous section.
  918.  
  919.    The sequence number, fragment number and number of fragments fields
  920.    are included in triggered response and triggered acknowledgement com-
  921.    mands.
  922.  
  923.    The triggered request packet should also contain the 4 extra octets
  924.    corresponding to the sequence number, fragment number and number of
  925.    fragments fields - but set to zero.
  926.  
  927.    Because additional security information is included in RIP Version 2
  928.    packets, this MUST be appended to the triggered request and triggered
  929.    acknowledgement packets, as well as being present in the triggered
  930.    response packet.
  931.  
  932.    The version number becomes 2.  Other aspects of packet layout follow
  933.    reference [2].
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952. Meyer                                                          [Page 17]
  953.  
  954. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  955.  
  956.  
  957. 5. Netware Routing Information Protocol
  958.  
  959.    This section should be read in conjunction with references [3,4,5],
  960.    since it only describes differences from these specifications.
  961.  
  962.    Netware [3] is the trade name of Novell Research's protocols for com-
  963.    puter communication which are derived and extended from Xerox Network
  964.    System's (XNS) protocols [7].
  965.  
  966.    Netware supports a mechanism that allows routers on an internetwork
  967.    to exchange routing information using the Routing Information Proto-
  968.    col (RIP) which runs over the Internetwork Packet Exchange (IPX) pro-
  969.    tocol [4] using socket number 453h.
  970.  
  971.    Netware RIP and IP RIP share a common heritage, in that they are both
  972.    based on XNS RIP, but there is some divergence, mostly at the packet
  973.    format level to reflect the differing addressing schemes.
  974.  
  975.    The triggered update mechanism can be applied to Netware RIP.  To
  976.    support the mechanism outlined in this proposal the packet format for
  977.    Netware RIP [3,5] is modified as shown in Figure 3.
  978.  
  979.    Every datagram contains the following:
  980.  
  981.    RIP OPERATION
  982.  
  983.              Operations supported in standard Netware RIP are: request
  984.              (1) and response (2).
  985.  
  986.              The fields sequence number, fragment number and number of
  987.              fragments MUST NOT be included in packets with these opera-
  988.              tion values.
  989.  
  990.              The following new operations are required (with values
  991.              chosen to be the same as for IP RIP commands):
  992.  
  993.        TRIGGERED REQUEST (6)
  994.  
  995.                  A request for the responding system to send all of its
  996.                  routing database.
  997.  
  998.                  Only the first 2 octets of the packet format shown in
  999.                  figure 3 are sent, since all routing information is
  1000.                  implied by this request type.
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008. Meyer                                                          [Page 18]
  1009.  
  1010. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1011.  
  1012.  
  1013.  
  1014.      0                   1         1
  1015.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1016.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1017.      |       operation (2)           |
  1018.      +---------------+---------------+
  1019.  
  1020.         The following new fields are inserted for some operations
  1021.  
  1022.      0                   1                   2                   3 3
  1023.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1024.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1025.      |      sequence number (2)      | fragment (1)  |no of frags (1)|
  1026.      +-------------------------------+-------------------------------+
  1027.  
  1028.            Followed by up to 50 routing entries (each 8 octets)
  1029.  
  1030.      0                   1                   2                   3 3
  1031.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1032.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1033.      |                       network number (4)                      |
  1034.      +---------------------------------------------------------------+
  1035.      |       number of hops (2)      |      number of ticks (2)      |
  1036.      +---------------------------------------------------------------+
  1037.                                      .
  1038.                                      .
  1039.  
  1040.      The format of a Netware RIP datagram in octets, with each tick mark
  1041.      representing one bit.    All fields are in network order.
  1042.  
  1043.      The four octets: sequence  number  (2),  fragment  number  (1)  and
  1044.      number of fragments (1) are not present in the original RIP specif-
  1045.      ication.   They are only present if operation takes the values 7 or
  1046.      8.
  1047.  
  1048.  
  1049.         Figure 3.   Netware Routing Information Protocol packet format
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064. Meyer                                                          [Page 19]
  1065.  
  1066. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1067.  
  1068.  
  1069.        TRIGGERED RESPONSE (7)
  1070.  
  1071.                  A message containing all of the sender's routing data-
  1072.                  base, excluding those entries learned from the inter-
  1073.                  face to which the routing information is being sent.
  1074.  
  1075.                  This message may be sent in response to a triggered
  1076.                  request, or it may be an update message resulting from
  1077.                  a change in the routing database.
  1078.  
  1079.        TRIGGERED ACKNOWLEDGEMENT (8)
  1080.  
  1081.                  A message sent in response to every triggered response
  1082.                  packet received.
  1083.  
  1084.                  Only the first 6 octets of the packet format shown in
  1085.                  figure 3 are sent.
  1086.  
  1087.    SEQUENCE NUMBER
  1088.  
  1089.              This is a new field inserted if operation takes the values
  1090.              7 or 8.
  1091.  
  1092.              The sequence number MUST be incremented every time updated
  1093.              information is sent out on a WAN.  The sequence number
  1094.              wraps round at 65535.
  1095.  
  1096.              When a triggered acknowledgement is sent the sequence
  1097.              number is set to the same value as the triggered response
  1098.              packet being acknowledged.
  1099.  
  1100.    FRAGMENT NUMBER
  1101.  
  1102.              The fragment number is one for the first fragment of a
  1103.              routing update, and is incremented for each subsequent
  1104.              fragment.  A fragment can contain up to 50 routing entries.
  1105.  
  1106.              When a triggered acknowledgement is sent the fragment
  1107.              number is set to the same value as the triggered response
  1108.              packet being acknowledged.
  1109.  
  1110.              The sequence number MUST be identical over fragments.
  1111.  
  1112.    NUMBER OF FRAGMENTS
  1113.  
  1114.              This indicates the number of fragments required to complete
  1115.              the routing update.
  1116.  
  1117.  
  1118.  
  1119.  
  1120. Meyer                                                          [Page 20]
  1121.  
  1122. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1123.  
  1124.  
  1125.              A triggered acknowledgement should return the value
  1126.              obtained from the triggered response packet.
  1127.  
  1128.    For triggered response packets the rest of the datagram contains a
  1129.    list of networks, with information about each.  Each entry in this
  1130.    list contains a destination network, and the number of hops and
  1131.    number of ticks for each.
  1132.  
  1133.    The maximum datagram size is 406 octets, excluding the IPX header (a
  1134.    further 30 octets).
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176. Meyer                                                          [Page 21]
  1177.  
  1178. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1179.  
  1180.  
  1181. 6. Netware Service Advertising Protocol
  1182.  
  1183.    This section should be read in conjunction with references [3,4,6],
  1184.    since it only describes differences from these specifications.
  1185.  
  1186.    Netware [3] also supports a mechanism that allows servers on an
  1187.    internetwork to advertise their services by name and type using the
  1188.    Service Advertising Protocol (SAP) [6] which runs over the Internet-
  1189.    work Packet Exchange (IPX) protocol [4] using socket number 452h.
  1190.  
  1191.    SAP operates on similar principals to running RIP.  Routers act as
  1192.    SAP agents, collecting service information from different networks
  1193.    and relay it to interested parties.
  1194.  
  1195.    To support the triggered update mechanism outlined in this proposal
  1196.    the packet format for Netware SAP [3,6] is modified as shown in Fig-
  1197.    ure 4.
  1198.  
  1199.    Every Service Advertising Protocol datagram contains the following:
  1200.  
  1201.    SAP OPERATION
  1202.  
  1203.              Operations supported in standard Netware SAP are: general
  1204.              service query (1), general service response (2), nearest
  1205.              service query (3) and nearest service response (4).
  1206.  
  1207.              The fields sequence number, fragment number and number of
  1208.              fragments MUST NOT be included in packets with these opera-
  1209.              tion values.
  1210.  
  1211.              The following new operations are required:
  1212.  
  1213.        TRIGGERED GENERAL SERVICE QUERY (6)
  1214.  
  1215.                  A request for the responding system to send the identi-
  1216.                  ties of all servers of all types.
  1217.  
  1218.                  Only the first 2 octets of the packet format shown in
  1219.                  figure 4 are sent, since all service types are implied
  1220.                  by this request type.
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232. Meyer                                                          [Page 22]
  1233.  
  1234. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1235.  
  1236.  
  1237.  
  1238.      0                   1         1
  1239.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1240.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1241.      |       operation (2)           |
  1242.      +---------------+---------------+
  1243.  
  1244.         The following new fields are inserted for some operations
  1245.  
  1246.      0                   1                   2                   3 3
  1247.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1248.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1249.      |      sequence number (2)      | fragment (1)  |no of frags (1)|
  1250.      +-------------------------------+-------------------------------+
  1251.  
  1252.            Followed by up to 8 service entries (each 66 octets)
  1253.  
  1254.      0                   1                   2                   3 3
  1255.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1256.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1257.      |                       Service Type (4)                        |
  1258.      +---------------------------------------------------------------+
  1259.      |                       Service Name (48)                       |
  1260.      +                                                               +
  1261.                                   .
  1262.      |                            .                                  |
  1263.      +---------------------------------------------------------------+
  1264.      |                       Network Address (4)                     |
  1265.      +---------------------------------------------------------------+
  1266.      |                        Node Address (6)                       |
  1267.      +                               +-------------------------------+
  1268.      |                               |      Socket Address (2)       |
  1269.      +---------------------------------------------------------------+
  1270.      |       Hops to Server (2)      |
  1271.      +-------------------------------+
  1272.                                      .
  1273.                                      .
  1274.  
  1275.      The format of a Netware SAP datagram in octets, with each tick mark
  1276.      representing one bit.  All fields are in network order.
  1277.  
  1278.      The four octets: sequence  number  (2),  fragment  number  (1)  and
  1279.      number of fragments (1) are not present in the original SAP specif-
  1280.      ication.  They are only present if operation takes the values 7  or
  1281.      8.
  1282.  
  1283.  
  1284.         Figure 4.   Netware Service Advertising Protocol packet format
  1285.  
  1286.  
  1287.  
  1288. Meyer                                                          [Page 23]
  1289.  
  1290. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1291.  
  1292.  
  1293.        TRIGGERED GENERAL SERVICE RESPONSE (7)
  1294.  
  1295.                  A message containing all of the sender's services
  1296.                  table, excluding those entries learned from the inter-
  1297.                  face to which the routing information is being sent
  1298.                  out.
  1299.  
  1300.                  This message may be sent in response to a triggered
  1301.                  general service query, or it may be an update message
  1302.                  resulting from a change in the routing database.
  1303.  
  1304.        TRIGGERED GENERAL SERVICE ACKNOWLEDGEMENT (8)
  1305.  
  1306.                  A message sent in response to every triggered general
  1307.                  service response packet received.
  1308.  
  1309.                  Only the first 6 octets of the packet format shown in
  1310.                  figure 4 are sent.
  1311.  
  1312.    SEQUENCE NUMBER
  1313.  
  1314.              This is a new field inserted if operation takes the values
  1315.              7 or 8.
  1316.  
  1317.              The sequence number MUST be incremented every time updated
  1318.              information is sent out on a WAN.  The sequence number
  1319.              wraps round at 65535.
  1320.  
  1321.              When a triggered general service acknowledgement is sent
  1322.              the sequence number is set to the same value as the trig-
  1323.              gered general service response packet being acknowledged.
  1324.  
  1325.    FRAGMENT NUMBER
  1326.  
  1327.              The fragment number is one for the first fragment of a
  1328.              triggered general service response update, and is incre-
  1329.              mented for each subsequent fragment.  A fragment can con-
  1330.              tain up to 8 service entries.
  1331.  
  1332.              When a triggered general service acknowledgement is sent,
  1333.              the fragment number is set to the same value as the trig-
  1334.              gered general service response packet being acknowledged.
  1335.  
  1336.              The sequence number MUST be identical over fragments.
  1337.  
  1338.    NUMBER OF FRAGMENTS
  1339.  
  1340.              This indicates the number of packets required to complete
  1341.  
  1342.  
  1343.  
  1344. Meyer                                                          [Page 24]
  1345.  
  1346. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1347.  
  1348.  
  1349.              the service update.
  1350.  
  1351.              A triggered general service acknowledgement should return
  1352.              the value obtained from the triggered general service
  1353.              response packet.
  1354.  
  1355.    For triggered general service response packets the rest of the
  1356.    datagram contains a list of services, with information about each.
  1357.    Each entry in this list contains the service type, service name, full
  1358.    address (network, node and socket), and the number of hops to the
  1359.    server.
  1360.  
  1361.    The maximum datagram size is 534 octets, excluding the IPX header (a
  1362.    further 30 octets).
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400. Meyer                                                          [Page 25]
  1401.  
  1402. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1403.  
  1404.  
  1405. 7. Timers
  1406.  
  1407.    A number of timers must be supported to handle the triggered update
  1408.    mechanism:
  1409.  
  1410.    o  Database timer.
  1411.  
  1412.    o  Retransmission timer.
  1413.  
  1414.    o  Reassembly timer.
  1415.  
  1416.    In this section appropriate timer values for IP RIP are suggested.
  1417.  
  1418.    For other routing protocols, only the database timer should need to
  1419.    take different values.  The database timer values are chosen to match
  1420.    equivalent timer operation for using the protocol on a LAN.  The
  1421.    behavior of a routing entry when a timer is running becomes indistin-
  1422.    guishable from a routing entry learned from a broadcast update.
  1423.  
  1424. 7.1 Database Timer
  1425.  
  1426.    Routes learned by a triggered response command (7) are normally con-
  1427.    sidered to be permanent - that is they do NOT time out unless
  1428.    activated by one of the following events:
  1429.  
  1430.    o  If the circuit manager indicates that a next hop router cannot be
  1431.       contacted, all routes learned from that next hop router should
  1432.       start timing out as if they had (just) been learned from a conven-
  1433.       tional response command (2).
  1434.  
  1435.       Namely each route exists while the database entry timer is running
  1436.       and is advertised on other interfaces as if still present.  The
  1437.       route is then advertised as unreachable while a further hold down
  1438.       timer is allowed to expire, at which point the entry is deleted.
  1439.  
  1440.       If the circuit manager indicates that the next hop router can be
  1441.       contacted while the database entry timer is running, the routes
  1442.       are reinstated as permanent entries.
  1443.  
  1444.       If the database entry timer has expired and the circuit manager
  1445.       indicates that the next hop router is reachable, the routing pro-
  1446.       tocol must issue a triggered request.  The routes will be rein-
  1447.       stated on the basis of any triggered response packet(s) received.
  1448.  
  1449.    o  If a triggered response packet is received in which a route is
  1450.       marked unreachable, the hold down timer MUST be started and the
  1451.       entry is advertised as unreachable on other interfaces.  On expiry
  1452.       of the hold down timer the entry is deleted.
  1453.  
  1454.  
  1455.  
  1456. Meyer                                                          [Page 26]
  1457.  
  1458. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1459.  
  1460.  
  1461.       If a triggered response packet is received in which an existing
  1462.       route is ABSENT, the hold down timer MUST also be started and the
  1463.       entry is advertised as unreachable on other interfaces.  On expiry
  1464.       of the hold down timer the entry is deleted.
  1465.  
  1466.    For IP RIP the hold down timer should always run for 120 seconds, to
  1467.    be consistent with RIP usage on broadcast networks.  The database
  1468.    entry timer should by default run for 180 seconds.  The network can
  1469.    be made more responsive by reducing the database entry timer value.
  1470.    However making this timer too short can lead to network instabili-
  1471.    ties.  The duration of the database entry timer allows a period of
  1472.    grace in which contention for network resources can be resolved by
  1473.    the circuit manager.
  1474.  
  1475. 7.2 Retransmission Timer
  1476.  
  1477.    The routing task runs a retransmission timer:
  1478.  
  1479.    o  When a triggered request is sent it will be retransmitted periodi-
  1480.       cally while a triggered response packet is not received.
  1481.  
  1482.    o  When a triggered response is sent a note of the sequence number
  1483.       and fragment number(s) of the routing update is kept.
  1484.  
  1485.       Fragments will be retransmitted at periodic intervals while a
  1486.       triggered acknowledgement packet is not received for the appropri-
  1487.       ate fragment.
  1488.  
  1489.    With call set up time on the WAN being of the order of a second, a
  1490.    value of 5 seconds for the retransmission timer is appropriate.
  1491.  
  1492.    If the circuit manager indicates that the next hop router is unreach-
  1493.    able, the retransmission is suppressed until the circuit manager
  1494.    indicates that the next hop router is reachable once more.
  1495.  
  1496.    Retransmissions should not run indefinitely, since a lack of response
  1497.    (when a circuit is up) is most likely caused by incorrect configura-
  1498.    tion of the next hop router.
  1499.  
  1500. 7.3 Reassembly Timer
  1501.  
  1502.    When a router receives a triggered response update it MUST ack-
  1503.    nowledge each fragment.  If the routing update is fragmented over
  1504.    more than one packet, the receiving router MUST store the fragments
  1505.    until ALL fragments are received.
  1506.  
  1507.    On receiving the first fragment a timer should be started.  If all
  1508.    fragments of the routing update are not received within that period
  1509.  
  1510.  
  1511.  
  1512. Meyer                                                          [Page 27]
  1513.  
  1514. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1515.  
  1516.  
  1517.    they are discarded - and a triggered request is sent back to the ori-
  1518.    ginator (with retransmissions if necessary).  The originator MUST
  1519.    then resend ALL triggered response fragments
  1520.  
  1521.    The reassembly timer should be set to four times the value of the
  1522.    retransmission timer.  With a suggested retransmission timer value of
  1523.    5 seconds, the suggested reassembly timer value SHOULD be 20 seconds.
  1524.  
  1525.    Implementations MAY allow the reassembly timer and retransmission
  1526.    timer to be configurable (in the 1:4 ratio), but interoperability
  1527.    will be compromised on WANs where all participating routers DO NOT
  1528.    support the same values for these timers.
  1529.  
  1530.    Fragments MUST also be discarded if a new fragment with a different
  1531.    sequence number is received.  A triggered request MUST not be sent in
  1532.    this instance.
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568. Meyer                                                          [Page 28]
  1569.  
  1570. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1571.  
  1572.  
  1573. 8. Security Considerations
  1574.  
  1575.    Security is provided my a number of aspects:
  1576.  
  1577.    o  The circuit manager is required to be provided with a list of phy-
  1578.       sical addresses to enable it to establish a call to the next hop
  1579.       router on an X.25 SVC or ISDN B-channel.
  1580.  
  1581.       The circuit manager MUST only allow incoming calls to be accepted
  1582.       from the same well defined list of routers.  The circuit manager
  1583.       MAY enforce additional security by not accepting incoming calls.
  1584.  
  1585.       Elsewhere in the system there will be a set of logical address and
  1586.       physical address tuples to enable the network protocols to run
  1587.       over the correct circuit.  This may be a lookup table, or in some
  1588.       instances there may be an algorithmic conversion between the two
  1589.       addresses.
  1590.  
  1591.    o  The routing (or service advertising) task MUST be provided with a
  1592.       list of logical addresses to which triggered updates are to be
  1593.       sent on the WAN.  The list MAY be a subset of the list of next hop
  1594.       routers maintained by the circuit manager.
  1595.  
  1596.       There MAY also be a separate list of next hop routers to which
  1597.       traditional broadcasts of routing (or service advertising) updates
  1598.       should be sent.  Next hop routers omitted from either list are
  1599.       assumed to be not participating in routing (or service advertis-
  1600.       ing) updates.
  1601.  
  1602.       The list (or lists) doubles as a list of routers from which rout-
  1603.       ing updates are allowed to be received from the WAN.  Any routing
  1604.       information received from a router not in the appropriate list
  1605.       MUST be discarded.
  1606.  
  1607. References
  1608.  
  1609.  
  1610.    [1]  Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
  1611.         University, June 1988.
  1612.  
  1613.    [2]  Malkin. G., "RIP Version 2 - Carrying Additional Information",
  1614.         Internet Draft, Xylogics, July 1992.
  1615.  
  1616.    [3]  Novell Incorporated., "Netware Application Notes", 1990.
  1617.  
  1618.    [4]  Novell Incorporated., "Netware V2.1 Internetwork Packet Exchange
  1619.         Protocol (IPX) with Asynchronous Event Scheduler (AES)", Febru-
  1620.         ary 1988 Document Revision 1.00.
  1621.  
  1622.  
  1623.  
  1624. Meyer                                                          [Page 29]
  1625.  
  1626. Internet Draft     Routing over Demand Circuits - RIP      November 1992
  1627.  
  1628.  
  1629.    [5]  Novell Incorporated., "Netware V2.1 Routing Information Protocol
  1630.         (RIP)", February 1988 Document Revision 1.00.
  1631.  
  1632.    [6]  Novell Incorporated., "Netware V2.1 Service Advertising Protocol
  1633.         (SAP)", February 1988 Document Revision 1.00.
  1634.  
  1635.    [7]  Xerox Corporation., "Internet Transport Protocols", Xerox System
  1636.         Integration Standard XSIS 028112, December 1981.
  1637.  
  1638.    [8]  Moy, J. "OSPF version 2", RFC 1247, Proteon Inc, July 1991.
  1639.  
  1640.    [9]  ISO/DIS 10589, "Intermediate system to Intermediate system
  1641.         Intra-Domain routing exchange protocol for use in conjunction
  1642.         with the protocol for providing the connectionless-mode network
  1643.         service (ISO 8473)"
  1644.  
  1645.    [10] ISO 8473, Protocol for providing the connectionless-mode network
  1646.         service", RFC 994.
  1647.  
  1648.    [11] Malis. A., Robinson. D., and Ullmann. R., "Multiprotocol Inter-
  1649.         connect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN Com-
  1650.         munications, Computervision Systems Integration and Process
  1651.         Software Corporation.
  1652.  
  1653. Author's  Address:
  1654.  
  1655.    Gerry Meyer
  1656.    Spider Systems
  1657.    Stanwell Street
  1658.    Edinburgh EH5 6NG
  1659.    Scotland, UK
  1660.  
  1661.    Phone: (UK) 31 554 9424
  1662.    Fax:   (UK) 31 554 0649
  1663.    Email: gerry@spider.co.uk
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680. Meyer                                                          [Page 30]
  1681.  
  1682.  
  1683.  
  1684.  
  1685.